Computer systems, such as smartphones, personal digital assistants, tablets, netbooks, laptops, and desktops, typically include a processor, communication unit such as a bus, power supply, and, optionally, a housing unit. Often, computer systems are configured to function with peripheral devices, which are termed “devices” for purposes of this application.
Certain devices are categorized by the position of each relative to a housing unit. Specifically, internal devices—called also “integrated devices”—generally are stored inside or integrated with the housing unit. Such integrated devices may include an internal hard drive, CD-R drive, CD-ROM drive, DVD-ROM drive, sound card, network card, video adapter, or an internal modem. External devices generally are stored outside of the housing unit and may include a printer, scanner, monitor, touchscreen, keyboard, or pointing devices such as a mouse, gaming controller, or joystick.
Devices may be categorized also by function. Specifically, storage devices may include an external hard drive, flash drive, disk drive, or any other device configured to permit information storage. Input devices may include keyboard, pointing devices such as a mouse, gaming controller, or joystick, digital camera, webcam, barcode reader, microphone, fingerprint scanner, or any other device configured to permit input of information into the computer. Output devices may include display devices such as a monitor, segment display such as a digital clock display, television set, or tactile electronic display, audio output devices such as speakers or headphones, printers, or any other device configured to permit information output from the computer.
An objective of many devices is to provide an output that is perceivable by a user. For purposes of this application, a “perceivable output” may include any perceptible output from the device including, for example, that which is viewable on a display, a touchable button, a light, or stored information. Other perceivable outputs may be input from one device—e.g., a keyboard or a mouse—and perceived as an output on a display device—such as a monitor or a touchscreen.
Computer systems can use hardware, software, or both to manage the resources of the computer system. Software used to manage a computer system's resources is termed an “operating system”. When a user seeks to use a device with a computer system, the operating system may not have the information necessary to communicate with that device. Because of the plethora of devices available to connect with computer systems, it would be impractical to include the information necessary for communicating with every device in every operating system. Accordingly, a software program—called a “device driver” or “driver”—allows the device and operating system to communicate with each other. Generally, at least one driver is available for every type of device. At times, a driver may be developed for each of multiple operating systems (e.g., Microsoft Windows, Mac OS X, Android, Linux, BSD, etc.). When the driver permits communication between the operating system and a real device, the device can perform its function to generate a perceivable output.
Drivers also may be used to facilitate communication between the operating system and an application program. An application program—termed more simply an “app”—generally is configured to permit the user to perform a specific task. Popular apps may include word processing programs, image editing programs, game programs, database management programs, and document management programs. Certain apps may be configured for use specifically with a device. Such an app is termed a “device application program” for purposes of this application.
Conventionally, a driver or an app utilizing a device through the driver could not be developed until the real device, or at least a stable prototype of the real device, was completed. Clearly, such a delay in the development and validation of the driver further delays offering of the product for sale. At times, developers begin designing drivers based on predictions of the real device. For purposes of this application, the “real device” is the physical device as offered to consumers or other end-users. When the real device becomes available, draft versions of the driver often require substantial revisions, which results in a largely inefficient process.
To shorten the development cycle, systems have been built to enable earlier development of a driver. One such approach includes using an early prototype such as a Field-Programmable Gate Array (“FPGA prototype”) for driver development. However, such prototypes can delay the start of driver development until the register transfer level (“RTL”) design of the device is generally finished. Also, an FPGA prototype may differ significantly from the real device. As a result, the driver developed to work with that prototype may need significant revision in order that it can function with the real device.
In addition, known approaches for testing an FPGA prototype, or even the real device, during driver development permit only limited observation of the internal conditions of the prototype or device. Also, prototypes and real devices generally do not permit recording events that occurred, for example, before an error, and are difficult to control without a time-consuming and labor-intensive bootstrapping process.
Another approach to enable the development of a driver involves the utilization of virtual machines and virtual devices. A “virtual machine” is a software program configured to simulate the operation of certain hardware or operating system with minimal access to the actual hardware or operating system in the host computer system. In certain embodiments, a virtual machine is a simulated computer system operating within, but generally isolated from, a physical computer system. A “virtual device” is a software program configured to simulate the operation of or function as a real device without access to the real device or a prototype of the real device. Certain embodiments of a virtual device may be configured to have the same functional restrictions and other restrictions as real devices. A virtual device may be presented as a display that represents a real device.
Virtual devices may operate within an environmental infrastructure such as a virtual machine or an operating system. When functioning in a virtual machine, a guest operating system may interact with a virtual device as if it is a real device. This requires no change to the driver stack of the guest operating system. In contrast, when functioning in a non-virtual operating system, an operating system may be extended to allow loading of a virtual device as if it is a real device. This involves changing the driver stack of the operating system. An example of this approach is the Device Simulation Framework (“DSF”), which allows introduction of virtual devices that model and simulate Universal Serial Bus (“USB”) devices in an operating system.
While certain virtual devices are known, such virtual devices have not been optimized for device simulation and driver development. Specifically, certain known virtual devices are too simple to permit development of a driver that consistently functions with the real device. Other known virtual devices are too complex to create an efficient simulation. For example, certain virtual devices permit observation, tracking, and control of the device, but often result in excess performance overhead and cause the simulation to operate slowly.
In addition, known virtual devices use concrete execution of software code. In other words, to achieve a certain task, a program may execute instructions that include one or more if-then statements (e.g., if A, then B; if not A, then C). In concrete execution, the developer must pre-determine which choice the program will make at each decision point. Accordingly, to simulate each real device behavior, a developer must explicitly specify concrete values and choices or supply run-time scripts for each device behavior. Such virtual devices render it difficult to conduct comprehensive exploration of possible device behaviors and simulation of the possible concurrency in device-driver interaction.
Other known device simulations are not configured to operate in virtual machine such as DSF and a Quick EMUlator (“QEMU”) virtual machine. Such simulations include those generated from device designs at different stages within the development process, for example, transaction-level (“TL”) designs in SystemC or SystemVerilog, register-transfer-level (“RTL”) designs in Verilog or VHDL, and gate-level (“GL”) designs as net-lists.
In addition, methods for preparing testing protocols for known virtual devices and the co-developed drivers typically must be generated manually or on a one-by-one basis, which is time-intensive and cost-prohibitive.
Clearly, there is a demand for a system and methods for constructing virtual devices that incorporate various levels of detail from a device design, developing a driver or application program with improved performance, and preparing automated testing protocols for validating a driver, driver-device combination, or application program, where such system and methods are configured to maximize the smooth integration of the resulting driver or application program with a real device. The present invention satisfies this demand.